J'ai installé sur mon pi raspbery (debian buster) un serveur nextcloud.
J'essaie de me connecter à mon serveur avec ssh mais, j'obtiens ceci :
$ ssh pi@192.168.1.36
> ssh : connect to host 192.168.1.36 port 22 : Connexion refusée
Sur mon serveur, je lance la commande : sudo systemctl status sshd, j'obtiens :
● ssh.service - Serveur OpenBSD Secure Shell
Loaded : chargé (/lib/systemd/system/ssh.service ; activé ; vendor preset : activé)
Actif : échec (Résultat : code de sortie) depuis Mon 2020-04-13 21:28:55 CEST ; il y a 17h
Docs : man:sshd(8)
man:sshd_config(5)
Processus : 622 ExecStartPre=/usr/sbin/sshd -t (code=sortie, statut=1/FAILURE)
13 avril 21:28:55 systemd [1] : ssh.service : Service RestartSec=100ms expiré, redémarrage de la programmation.
13 avril 21:28:55 systemd [1] : ssh.service : Redémarrage programmé, le compteur de redémarrage est à 5.
13 avril 21:28:55 systemd [1] : ssh.service : Redémarrage programmé, le compteur de redémarrage est à 5 : Arrêtez le serveur OpenBSD Secure Shell.
13 Avril 21:28:55 systemd [1] : ssh.service : Demande de démarrage répétée trop rapidement.
13 Avril 21:28:55 systemd [1] : ssh.service : Echec avec le résultat "exit-code".
13 avril 21:28:55 systemd[1] : Echec du démarrage du serveur OpenBSD Secure Shell.
Quand je fais sudo apt purge openssh-server -y ; sudo apt install openssh-server -y
.
Le serveur ssh fonctionne à nouveau pendant environ 20 minutes, puis s'arrête de fonctionner.
Pouvez-vous m'aider ?
Merci.
# Serveur en mode debug
Posté par Walter . Évalué à 2.
Salut,
lance ton serveur ssh en mode debug : /usr/sbin/sshd -d -p 22
comme ça tu pourras voir pourquoi il plante dans la console
# Logs?
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 3.
Que dit
journalctl --since "-1 hour"|grep ssh
?
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: Logs?
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 3.
Et je te recommande de remplacer tes ; par des && dans tes one-liners :)
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: Logs?
Posté par bug . Évalué à 1. Dernière modification le 15 avril 2020 à 11:32.
Bonjour,
Merci pour toutes vos réponses!
Voici le résultat de la commande "journalctl --since "-1 hour"|grep ssh"
La commande
/usr/sbin/sshd -d -p 22
: Renvoie quelque chose de similaireJ'ai donc essayé :
ssh-keygen -A
Sans succèsAuriez-vous une idée du problème ?
Merci d'avance.
[^] # Re: Logs?
Posté par NeoX . Évalué à 3.
2problemes d'apres les LOGs
ligne 84, l'option UsePAM ne semble pas être appréciée
il ne semble pas trouvé les clefs, ou les clefs n'ont pas les bons droits.
si tu as la main physiquement sur la machine,
sauvegarde les fichiers de configs et les clefs
tar zxcvf /root/openssh-down.tgz /etc/ssh* /etc/sshd*
supprimes tout
reinstalle
apt install opens-server
ca va remettre le fichier de config par défaut, refaire les clefs SSHs
[^] # Re: Logs?
Posté par bug . Évalué à 1. Dernière modification le 16 avril 2020 à 10:09.
Bonjour,
Merci pour votre réponse, j'ai bien fait ce que vous m'avez demandé mais après 10-15 minutes le serveur coupe la connexion et impossible de m'y reconnecter.
C'est à perdre la tête :).
[^] # Re: Logs?
Posté par aiolos . Évalué à 1.
Si les clefs disparaissent en cours d'utilisation, ce ne serait pas un problème sur un disque ?
[^] # Re: Logs?
Posté par bug . Évalué à 1.
Les clefs sont toujours présentes mais impossible des les utiliser. Si c'est un problème de disque pourquoi il y a que ssh qui plante ?
[^] # Re: Logs?
Posté par NeoX . Évalué à 2.
et il n'y a que SSH qui plante, ou la machine n'est plus du tout joignable, en web, en ftp, en vnc… ?
[^] # Re: Logs?
Posté par bug . Évalué à 1.
Il y a bien que le serveur ssh qui plante sinon tout fonctionne parfaitement (apache, mariadb…).
[^] # Re: Logs?
Posté par NeoX . Évalué à 2.
problème d'espace disque saturé ?
SSH a besoin d'écrire sur le disque quand on se connecte
apache et mariaDB sont généralement en lecture, sauf quand on upload un fichier, ou quand on ajoute des données sur le disque
[^] # Re: Logs?
Posté par Thibault (site web personnel) . Évalué à 1.
Salut,
Le premier truc bizarre, c'est que sshd est tué violemment (SIGKILL). Cela ne devrait pas arriver naturellement. Peut-être un problème de pas assez de mémoire ?
Je te suggère d'aller vérifier dans le journal ce qui se passe autour de 10:30:32.
Le second truc bizarre c'est que tu sembles arriver à démarrer ssh à la main, mais avec l'unit de systemd cela ne fonctionne pas. C'est la même configuration utilisée entre le démarrage à la main et le démarrage via systemd (tu peux aller voir le fichier unit ssh.service ce qu'il y a dedans et lancer la même commande, normalement tu devrais avoir le même résultat). Cela pourrait potentiellement venir d'un problème de droit sur tes clefs.
Bon courage.
[^] # Re: Logs?
Posté par bug . Évalué à 1. Dernière modification le 17 avril 2020 à 19:06.
Bonjour,
Merci pour vos réponses.
Je pense que le problème d'espace peut-être écarté. Voici le retour de df -h:
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/root 118G 107G 5,9G 95% /
devtmpfs 465M 0 465M 0% /dev
tmpfs 469M 0 469M 0% /dev/shm
tmpfs 469M 24M 446M 6% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 469M 0 469M 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 53M 200M 21% /boot
tmpfs 94M 0 94M 0% /run/user/1000
Voici le fichier ssh.service
En effet, quand je fais /usr/sbin/sshd -t j'ai les même erreurs.
Could not load host key…
Si c'est un problème de droit comment lui donner ?
P.S : J'ai remarqué quand je fais
apt install openssh-server
après l'avoir désinstallé, il y a cette ligne :rescue-ssh.target is a disabled or a static unit, not starting it.
Merci
[^] # Re: Logs?
Posté par NeoX . Évalué à 2.
ton disque est plein (107Go occupé pour 118Go total, reste 5.9Go, soit 5%)
seul root peut travailler dedans, sur les 5% restants
fait un peu de place sur ton disque, et ca devrait rentrer dans l'ordre
[^] # Re: Logs?
Posté par bug . Évalué à 1. Dernière modification le 18 avril 2020 à 14:39.
J'ai fais un peux de place comme vous me l'avez demandé, j'ai maintenant 32GO de libre.
J'ai aussi fais un redémarrage mais le problème persiste. :)
[^] # Re: Logs?
Posté par NeoX . Évalué à 2.
toujours à 15/20minutes, ou ca tient plus longtemps ?
si tu laisses une ligne ssh ouverte, et que tu surveilles l'espace disque, et quelques valeurs, ca dit quoi ?
avec screen ou tmux, tu peux avoir plusieurs "écrans" pour afficher
top
ouhtop
dans l'unwatch df -h
dans un autre,parce que c'est vraiment bizarre ton ssh qui se stoppe tout seul.
tu as regardé la RAM utilisée (free -m ou top)
voire dans les logs si ssh se fait OOMkillé (OutOfMemory Kill),
c'est un truc qui tu les process qui consomment trop
[^] # Re: Logs?
Posté par bug . Évalué à 1.
Merci pour votre réponse,
Quand la connexion se coupe le RAM reste constante (300Mo/1Go), quand a l'espace disque libre il ne change pas.
Je n'ai pas trouvé le moyen de le trouver dans les logs, comment faire s'il vous plaît ?
[^] # Re: Logs?
Posté par NeoX . Évalué à 2.
en ligne de commande je fais ca
le fichier log peut être messages, syslog, daemon.log ca depend des distributions
[^] # Re: Logs?
Posté par benoar . Évalué à 2.
Tu t'es fait trouer ? La première fois que SSH est lancé, il se lance sans problème et ne dit pas avoir d'option inconnue dans la config. De plus, les clés doivent bien exister à ce moment-là.
Ensuite, un KILL sorti de nulle part, et redémarrage avec une conf différente (ou un binaire différent ne supportant pas PAM), et les clés manquantes ? J'imagine en fait un binaire spécifique compilé par un attaquant, avec des clés statiques dedans où un truc du genre.avril 15 10:08:31 sshd[4575]: Server listening on 0.0.0.0 port 22.
avril 15 10:08:31 sshd[4575]: Server listening on :: port 22.
Bref, quelqu'un est en train de faire quelque-chose dans ton dos, ou a (plus probablement) installé un RAT ou autre truc du genre. Vérifie que ta machine n'est pas infectée.
# Commentaire supprimé
Posté par Yosinbb . Évalué à 0. Dernière modification le 17 avril 2020 à 08:53.
Ce commentaire a été supprimé par l’équipe de modération.
# re
Posté par bug . Évalué à 1.
Cependant la RAM + plus le cache semble saturé la mémoire
[^] # Re: re
Posté par bug . Évalué à 1.
Non, après plusieurs essaie la RAM est à environ 120Mo et le server ssh plante toujours
# re
Posté par bug . Évalué à 1.
Je sais que mon problème est un peux bizzard mais si vous avez une idée je suis preneur.
:)
[^] # Re: re
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 2.
Que donne
ls -als /etc/ssh/*key
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: re
Posté par bug . Évalué à 1.
Bonjour,
Merci pour votre message
Voici le retour de ls -als /etc/ssh/*key
4 -rw------- 1 root root 513 avril 21 11:51 /etc/ssh/ssh_host_ecdsa_key
4 -rw------- 1 root root 411 avril 21 11:51 /etc/ssh/ssh_host_ed25519_key
4 -rw------- 1 root root 1823 avril 21 11:51 /etc/ssh/ssh_host_rsa_key
[^] # Re: re
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 2.
J'ai vu que tu avais réglé le problème, extra. Mais pour être complet, je remarque que le log mentionne
Could not load host key: /etc/ssh/ssh_host_dsa_key
Et que cette clé n'est pas dans le résultat du
ls
La gelée de coings est une chose à ne pas avaler de travers.
# Solution
Posté par bug . Évalué à 2.
Bonjour à tous !!
J'ai trouvé le problème, le système de fichier était HS.
Merci pour votre aide
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.